home *** CD-ROM | disk | FTP | other *** search
- Path: hell.team17.com!news
- From: boberg@team17.com (Stefan Boberg)
- Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.games,alt.sys.amiga.demos,comp.sys.amiga.misc
- Subject: Re: AB3D II beats Quake....
- Date: Wed, 03 Apr 1996 15:25:40 GMT
- Organization: Team 17 Software Ltd.
- Message-ID: <4ju1qf$k4@hell.team17.com>
- References: <DosA8o.17B@info.uucp> <6538.6658T1031T2526@mbox.vol.it> <4jgn4o$l2b@hell.team17.com> <4jk515$q3l@nadine.teleport.com> <4jkdpu$1o6@hell.team17.com> <4joj14$ghj@nadine.teleport.com> <4js275$98s@hell.team17.com> <4jt8bh$a70@nadine.teleport.com>
- NNTP-Posting-Host: zonk.team17.com
- X-Newsreader: Forte Free Agent 1.0.82
-
- sschaem@teleport.com (Stephan Schaem) wrote:
- >Stefan Boberg (boberg@team17.com) wrote:
-
- >: > I think they should do more then just the scan conversion...
-
- >: Such as?
-
- > Clipping, geometry transform, bsp tree traversal, visibility test
-
- BSP tree traversal? I have to disagree. That's the type of thing
- compilers are good at optimizing.
-
- Clipping/geometry transform: Possibly, although as far as I can see
- from my experiments, the gain is quite small.
-
- >: I'm not sure about that. In DOOM, very little was in ASM.
-
- > This just mean Doom pass most of its time in very little code.
-
- So does any game.
-
- >: Yes you can do that. You simply use in-line assembly macros for
- >: fixed-point multiplies / divides etc. I have such a system and it
- >: works fine. Just change a switch (such as '-DFIXED_MATH') on the
- >: command line and all code will use fixed-point.
-
- > Do you get good performance from this?
-
- Yes. Watcom is very good at allocating registers for inline ASM.
- BTW, Id used the same approach in Doom.
-
- > Also I often find myself
- > otimizjng the fix point setting. not alway 16:16 or 8:8, but maybe
- > 8:24, 4:28 ...
-
- You can do this with macros too, if you really need to. It gets less
- manageable though.
-
- >: It's not bad practice. It's clever - on the Pentium, at least. Can
- >: you figure out why it's done?
-
- > Nope... because the scanline loop use no MUL. and FPU add are slower
- > and also you cant use FPU register directly as index or else
- > so FPU make sense in the setup when fmul are faster then imul and you
- > dont need to convert from ftoi all the time, otherwise not.
-
- You've missed it completely. You can use floats in scan conversion,
- and it's faster than fixed-point on the Pentium (about twice as fast,
- as a matter of fact). I'm sure if you just think about it, you'll see
- why. But you're right, it's NOT in the core pixel-drawing loop.
-
- >: Taking polygon structures (vertices and edges) and turning them into
- >: pixels.
-
- > does the edge include slope information? if so no reason to see a float
- > operation in the 'scan-conversion' loop.
-
- No. In my case, an edge is a reference to two vertices. It could
- include slope information though, as a further optimization.
-
- I should add that I focus most of my attention on
- perspective-correct texture mapping. But the same optimization
- strategies (involving floats) can be applied to affine tmapping.
-
- > Stephan
-
-
- ===============================================================
- Stefan Boberg boberg@team17.com
- "This, like, sucks in ways that we've never seen stuff suck
- before, so it's kinda cool!" - B&B
-
-